Only failure is the overly restrictive commit message format check. Should there be a standard for commits that fix two issues?

A couple comments:

1. YYYY/MM/DD HH:MM:SS.MMM adds a lot of bytes to the log, it may make sense to just use HH:MM:SS.MMM or even have a "epoch" at the top of the log then all reports are SS.MMM from T0.
2. The "ts" command for Unix adds timestamps to streams (surely not microsecond-accurate.)
3. Instead of compile-time optional, would it be helpful to have it be command-able?

1. YYYY/MM/DD HH:MM:SS.MMM adds a lot of bytes to the log, it may make sense to just use HH:MM:SS.MMM or even have a "epoch" at the top of the log then all reports are SS.MMM from T0.

I only need the format added. If someone requires additional formats they could address in a future issue.

2. The "ts" command for Unix adds timestamps to streams (surely not microsecond-accurate.)

I don't think this would help my specific need, wouldn't correlate to syslog timing or packet timestamps.

3. Instead of compile-time optional, would it be helpful to have it be command-able?

I only need it via config. If someone requires commandability they could address in a future issue.

Good suggestions, but given my current requirements this change is all I need. Hopefully the future work can be independent from this ?

I also want to get this week's award for addressing the oldest issue (2017!). So there's that :)

@dzbaker @dmknutsen - Is there a CCB action on this one or is it pending review?

@dzbaker @dmknutsen - Is there a CCB action on this one or is it pending review?

@jphickey is just giving it a quick review to make sure there are no conflicts with other stuff being developed. It should be merged in at the end of this week.

... just add the time ...

I'll do it! Much preferred from my perspective.

@dmknutsen @jphickey - removed option to exclude timestamp in 43270f5

@jphickey @skliper @dmknutsen I can fast track this and include it in this next bundle if that makes sense?

That being said, I dunno if this should close #93 ... The intent with that old idea is that EVS should call into the PSP for low level output. This is where you can make the 4 "output ports" go to different physical devices (depending on what the board has) and also attach different info per-port. That was the idea at least. Having 4 "output ports" in EVS without an mapping to the lower-level hardware seems to be an incomplete implementation of this, its been that way for years though.

This is the one to move to the PSP (at least how I interpret them):

• EVS "output ports" should be a function of the PSP #94

93 just cleans up how the bits are checked and paves the way for 94:

• Clean up EVS ports implementation #93

This is the one to move to the PSP (at least how I interpret them):

* [EVS "output ports" should be a function of the PSP #94](https://github.com/nasa/cFE/issues/94)

93 just cleans up how the bits are checked and paves the way for 94:

* [Clean up EVS ports implementation #93](https://github.com/nasa/cFE/issues/93)

Thanks, yes this makes sense. I'm OK with this closing #93. Maybe someday will get to implement #94 too, I'd still like to see that done.